A computer network is a geographically distributed collection of interconnected subnetworks, such as local area networks (LAN) that transport data between network nodes. As used herein, a network node is any device adapted to send and/or receive data in the computer network. Thus, in this context, “node” and “device” may be used interchangeably. The network topology is defined by an arrangement of network nodes that communicate with one another, typically through one or more intermediate nodes, such as routers and switches. In addition to intra-network communications, data also may be exchanged between neighboring (i.e., adjacent) networks. To that end, “edge devices” located at the logical outer-bound of the computer network may be adapted to send and receive inter-network communications. Both inter-network and intra-network communications are typically effected by exchanging discrete packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how network nodes interact with each other.
Each data packet typically comprises “payload” data prepended (“encapsulated”) by at least one network header formatted in accordance with a network communication protocol. The network headers include information that enables network nodes to efficiently route the packet through the computer network. Often, a packet's network headers include a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header as defined by the Transmission Control Protocol/Internet Protocol (TCP/IP) Reference Model. The TCP/IP Reference Model is generally described in more detail in Section 1.4.2 of the reference book entitled Computer Networks, Fourth Edition, by Andrew Tanenbaum, published 2003, which is hereby incorporated by reference as though fully set forth herein.
A data packet may originate at a source node and subsequently “hop” from node to node along a logical data path until it reaches its addressed destination node. The network addresses defining the logical data path of a data flow are most often stored as Internet Protocol (IP) addresses in the packet's internetwork header. IP addresses are typically formatted in accordance with the IP Version 4 (IPv4) protocol, in which network nodes are addressed using 32 bit (four byte) values. Specifically, the IPv4 addresses are denoted by four numbers between 0 and 255, each number usually delineated by a “dot.” A subnetwork may be assigned to an IP address space containing a predetermined range of IPv4 addresses. For example, an exemplary subnetwork may be allocated the address space 128.0.10.*, where the asterisk is a wildcard that can differentiate up to 254 individual nodes in the subnetwork (0 and 255 are reserved values). For instance, a first node in the subnetwork may be assigned to the IP address 128.0.10.1, whereas a second node may be assigned to the IP address 128.0.10.2.
A subnetwork is associated with a subnet mask that may be used to select a set of contiguous high-order bits from IP addresses within the subnetwork's allotted address space. A subnet mask length indicates the number of contiguous high-order bits selected by the subnet mask, and a subnet mask length of N bits is hereinafter represented as /N. The subnet mask length for a given subnetwork is typically selected based on the number of bits required to distinctly address nodes in that subnetwork. Subnet masks and their uses are more generally described in Chapter 9 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published January 2000, which is hereby incorporated by reference as though fully set forth herein.
By way of example, assume an exemplary subnetwork is assigned the IP address space 128.0.10.4, and the subnetwork contains two addressable (reachable) network nodes. In this case, 30 address bits are needed to identify the subnetwork 128.0.10.4, and the remaining two address bits are used to distinctly address either of the two nodes in the subnetwork. Thus, the subnetwork may be associated with a subnet mask length of /30 since only the first 30 most-significant bits of an IP address are required to uniquely address this subnetwork. As used herein, an “address prefix” is defined as the result of applying a subnet mask to a network address. For example, consider the address prefix 128.0.10.1 /24. In this case, the network portion of the prefix contains the 24 most-significant bits of the IP address 128.0.10.1, i.e., the network is 128.0.10.0, and the last 8 bits are used to identify hosts on that network.
A computer network may contain smaller groups of one or more subnetworks which may be managed as separate routing domains. As used herein, a routing domain is broadly construed as a collection of interconnected network nodes under a common administration. Often, a routing domain is managed by a single administrative entity, such as a company, an academic institution or a branch of government. Such a centrally-managed routing domain is sometimes referred to as an “autonomous system” and is often associated with a unique autonomous system (AS) number that distinguishes the AS within a larger network environment. In general, a routing domain may operate as an enterprise network, a service provider or any other type of network or subnetwork. Further, the routing domain may contain one or more edge devices (e.g., border routers) having “peer” connections to other edge devices in adjacent routing domains.
Network nodes in a routing domain are typically configured to forward data using predetermined paths from “interior gateway” routing protocols, such as conventional link-state protocols and distance-vector protocols. These interior gateway protocols (IGP) define the manner with which routing information and network-topology information is exchanged and processed in the routing domain. For instance, IGP protocols typically provide a mechanism for distributing a set of reachable IP subnetworks (address prefixes) among the intermediate nodes in the routing domain. As such, each intermediate node receives a consistent “view” of the domain's topology. Link-state protocols, such as the Open Shortest Path First (OSPF) and Intermediate-System-to-Intermediate-System (IS-IS) protocols, and distance-vector protocols, such as the Routing Information Protocol (RIP), are generally described in Sections 12.1-12.3 of the reference book entitled Interconnections, Second Edition, by Radia Perlman, published January 2000, which is hereby incorporated by reference as though fully set forth herein.
The Border Gateway Protocol (BGP) is usually employed as an “external gateway” routing protocol for routing data between autonomous systems. The BGP protocol is well known and generally described in Request for Comments (RFC) 1771, entitled A Border Gateway Protocol 4 (BGP-4), by Y. Rekhter et al., published March 1995, which is publicly available through the Internet Engineering Task Force (IETF) and is hereby incorporated by reference in its entirety. External BGP (eBGP) is often used to exchange routing information across routing domain boundaries. Internal BGP (iBGP) is a variation of the eBGP protocol and is often used to distribute inter-network reachability information (address prefixes) among BGP-enabled edge devices situated within the same routing domain. To implement iBGP, the edge devices must be “fully meshed,” i.e., such that every device is coupled to every other device by way of a TCP connection. In practice, conventional route reflectors are used to logically couple devices into a full mesh.
BGP-enabled edge devices perform various routing functions, including transmitting and receiving BGP messages and rendering routing decisions based on BGP routing policies. Each edge device maintains a local BGP routing table that lists feasible routes to reachable (i.e., accessible) network nodes. In the context of BGP, a “route” is defined as an address prefix and its associated path attributes. Periodic refreshing of the BGP routing table is generally not performed. However, the BGP-configured edge devices do exchange routing information under certain circumstances.
For example, when a BGP-enabled edge device initially connects to the network, the device identifies its directly-attached peers in neighboring ASes and then receives the entire contents of its peers' BGP routing tables. Thereafter, routing updates are incrementally disseminated among the interconnected BGP-enabled edge devices so that each device can construct a consistent view of the network topology. To that end, BGP update messages are typically used to advertise a list of address prefixes whose reachability information has changed in the BGP routing table. The BGP update message also may include one or more BGP attributes associated with the advertised prefixes. Conventional BGP attributes and their formats are generally well known and are described in more detail in Chapter 6 of the reference book entitled IP Switching and Routing Essentials, by Stephen A. Thomas, published 2002 which is hereby incorporated by reference in its entirety.
The concept of shared risk link groups (SRLG) has been introduced to reflect that failure of a single data link can result in failures at one or more other links. For instance, when different inter-domain data links share a common resource, such as an optical fiber or the like, they are said to participate in the same SRLG. That is, failure of the shared resource would result in the failures of each of the links whose data packets are transported using that shared resource. Similarly, when multiple edge devices in a first routing domain are attached to a common edge device in a second routing domain, the set of edge devices in the first domain may be members of the same shared risk node group (SRNG). In this case, a network failure at the common edge device would prevent each device in the SRNG from communicating with the failed edge device in the second domain.
SRLG membership information may be communicated among a set of fully-meshed edge devices using standardized extensions to conventional interior gateway routing protocols, such the OSPF and IS-IS protocols. In practice, a link is manually assigned, e.g., by a network administrator, to one or more SRLGs. The link is then associated with a different SRLG identifier for each of its assigned SRLGs. These identifiers are typically stored along with an identifier of the link in a type-length-value (TLV) tuple. Thereafter, the TLV is advertised within a routing domain to disseminate the link's SRLG information. For instance, SRLG TLVs for OSPF and IS-IS advertisements are respectively described in the IETF Internet Drafts draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, entitled OSPF Extensions in Support of Generalized Multi-Protocol Label Switching, dated October 2003, by Kompella et al. and draft-ietf-isis-gmpls-extensions-19.txt, entitled IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching, dated October 2003, by Kompella et al., both of which are hereby incorporated by reference as though fully set forth herein.
Although manual configuration of SRNG memberships also can be performed, such static SRNG configuration is impractical. For instance, manual SRNG configuration is excessively time consuming, since it requires a network administrator to examine each edge device in a routing domain to determine the device's directly-attached peers. Because the administrator may have to keep track of a large number of edge devices and complex network topologies, manual SRNG configuration can result in erroneous or accidental SRNG assignments. The above-noted problems are often compounded in response to changes in the network topology which necessitate updated SRNG assignments. For instance, if a link or node is added or removed at the edge of the routing domain, the network administrator may have to re-configure the SRNG memberships at least at those edge devices affected by the topology change.
It is therefore generally desirable to assign SRNG memberships to edge devices in a more efficient manner. The process of assigning SRNG memberships should be less time consuming and more reliable than manual configuration techniques, and the process should update SRNG memberships faster in response to network topology changes.